85 - 7.1.5 Stapelverarbeitung: Schutzvorkehrungen für Einprogrammbetrieb [ID:19243]
50 von 149 angezeigt

Nun mit einem residenten Steuerprogramm im Hauptspeicher bestand dann eigentlich das Problem

des Schutzes des Speicherbereiches, der von diesem Steuerprogramm eben wirklich belegt

wird. Man musste dafür Sorge tragen, dass diese transienten Anwendungsprogramme nicht in der Lage

gewesen wären, schreibend in diesen Speicherbereich des Steuerprogramms zuzugreifen und

damit das Steuerprogramm zu beeinträchtigen, letztendlich zum Absturz des Systems dadurch

beitragen zu können mit der weiteren Folge, dass dann wieder diese zeitaufwändige Hochfahrprozedur

mit dem Urladen dann durchgeführt werden musste. Und das war dann der Zeitpunkt, wo den Adressraumschutz

schon eine wesentliche Rolle spielte und die erste Form des Adressraumschutzes war die durch

Abgrenzung, Fencing. Hier hat man sogenannte Schutzgatter, also ein Fence eingeführt, die

den letztendlich dieses residente Steuerprogramm Hauptspeicher von den transienten Maschinenprogrammen

trennen. Das heißt also eigentlich zwei Partitionen eingeführt, wo denn fest verdrahtet in der

Hardware ab einer bestimmten Adresse praktisch so eine Grenze zwischen den jeweiligen Partitionen

festgeschrieben worden ist, mit der Konsequenz, dass ein Anwendungsprogramm, der nicht in der Lage

gewesen ist, erfolgreich aus seiner Partition in den Bereich des Steuerprogramms zugreifen zu können.

Anwendungsprogramme waren dann komplett statisch gebunden und diese Anfangsadresse dieses eines

solchen Anwendungsprogramms war denn praktisch, kann man sagen, diese Adresse, wo das Schutzgatter

liegt, das ist so eine Art Verlagerungskonstante, denn die beim Binden letztendlich die Ladeadresse

für dieses Programm, für so ein Anwendungsprogramm, den vorgibt. Das heißt, der Binder musste diese

Adresse kennen und hat denn alle Anweisungen und alle Datenbestände innerhalb dieses Anwendungsprogramms

entsprechend ab dieser Ladeadresse ausgerichtet. Das war eine reale Adresse, denn die Programme

wurden ja im realen Adressraum ausgeführt und wurden dann nachher entsprechend, wenn sie denn

zur Ausführung gebracht worden sind, immer genau in diese Partition, die an dieser Ladeadresse dann

begann, an dem Wert des Schutzgatters begann dann einfach platziert. Das war, wenn man eine feste

Fahrdrehdung hat, ein bisschen umständlich. Man hat dann eine bestimmte Flexibilität eingeführt,

indem man dann praktisch diesen Wert dieses Gatters in einen Register immer gehalten hat. Und das

waren dann die sogenannten Fansregister, dieses Schutzgatterregistermodell, was dann eingeführt

worden ist. Das führte dann letztendlich auch dazu, dass dann praktisch diese Verlagerungsadresse

keine Konstante mehr war beim Binden, sondern eher eine Variable. Die Programme wurden dann immer

relativ zur Basis 0 ausgerichtet, wie es auch heute typischerweise so üblich ist. Und dann war

denn zum Ladezeitpunkt ein verschiebener Ladeaktiv, der dann praktisch eine Relokation, eine Verlagerung

all der jeweiligen Adressen innerhalb dieses Programms durchgeführt hat. Und zwar mit dem

Verlagerungswert, den dann halt jeweils in diesen Schutzgatterregister, den letztendlich eingetragen

ist. Aber die Idee, ob das nun halt mit oder ohne Register funktionierte, waren eigentlich die

gleiche. Wenn also das Schutzgatter halt die Adresse, die da ruhig definiert gewesen ist,

denn letztendlich verletzend von dem Maschinenprogramm, von dem Anwendungsprogramm

genutzt worden wäre, wäre es dann eben zu einem Abbruch, zu einem Fehler gekommen. Nun,

innerhalb der jeweiligen Partition, insbesondere der Anwendungspartition, konnte man den Speicher

mehr oder weniger auch dynamisch zuteilen. Das war so typischerweise natürlich im Anwendungsbereich,

denn der Fall, man kann sich das so vorstellen, wie man den Haldenspeicher etwa eben auch innerhalb

des Anwendungsprogramms denn selbst dynamisch verwaltet, so halt hier praktisch eine Halde

innerhalb dieser Anwendungspartition. Typischerweise war es so, dass der Monitor eher eine statische

Speicherverwaltung als Grundlage hat. Er hätte es auch dynamisch machen können, aber da war der

Bedarf letztendlich für so ein Programmbetrieb noch nicht so hoch, dass man da unten innerhalb

des Monitors tatsächlich eine dynamische Speicherverwaltung hätte platzieren müssen. Nun,

das Problem mit einem Ansatz mit solchen festen Partitionen sind natürlich dann übergroße

Anwendungsprogramme, denn die mussten normal alle statisch komplett gebunden sein und sie mussten

eben doch vollständig in diese Partition, also in den Hauptspeicher passen. Bei sehr großen

Programmen war das natürlich dann schon ein Problem. Das, was man hier geschützt hat, ist der

Monitor nicht, aber das Anwendungsprogramm, das muss einem klar sein. Man hat denn praktisch

immer die Programmbereiche permanent isoliert, wenn man so will, die dann eben auch durchgängig

Teil einer Videoserie :

Zugänglich über

Offener Zugang

Dauer

00:16:07 Min

Aufnahmedatum

2020-07-06

Hochgeladen am

2020-07-06 21:56:26

Sprache

de-DE

Tags

module programmstruktur Variablen Datentypen Preprozessor Gültigkeit
Einbetten
Wordpress FAU Plugin
iFrame
Teilen